home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14151 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.9 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c,comp.unix.programmer
  4. Subject: Re: Q: '\n' character
  5. Date: 12 Apr 1996 00:16:12 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4kkvvsINN8fs@keats.ugrad.cs.ubc.ca>
  8. References: <4kj66f$k0o@ren.cei.net> <4kjh25INNf2e@anvil.ugrad.cs.ubc.ca> <4kko80$8np@news.ld.centuryinter.net>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4kko80$8np@news.ld.centuryinter.net>,
  12. Don & Gayle Peterson <dongayle@centuryinter.net> wrote:
  13. >It's a shame I didn't see the full original posting, but maybe your
  14. >solution is 'bullshit' too.
  15. >A long, long time ago, K&R taught me that the beauty in unix is
  16. >simplicity: don't re-invent a tool that already exists.  If all the
  17. >original author wants to do is read 2 (or more) files side by side,
  18. >what's wrong with good old pr?
  19. >or, getting fancier, and comparing them, sdiff?...depending on the
  20. >situation, get nuts, use paste... join...
  21. >
  22. >Getting raw side-by-side output from text files at the shell is as
  23. >simple as:
  24. >    pr -m file1 file2 ... 
  25. >or
  26. >    pr -t -m ....
  27. >if you don't want the pr header.
  28.  
  29. I sometimes recommend unix commands myself---for example when someone wanted to
  30. know how to delete lines from a text stream, I facetiously suggested ``sed''.
  31.  
  32. However, this is a C newsgroup, not comp.unix.shell. The C language is used in
  33. all kinds of places. It's somewhat arrogant to suggest UNIX solutions to C
  34. questions.
  35.  
  36. >If this requirement is within  C code where the multiple inputs
  37. >screw up the ability to use pipes, then forgive me for not knowing all
  38. >the facts. 
  39. >But,
  40. >The other response using strlen isn't 'wrong'; there are lots of
  41. >ways to skin a cat.
  42.  
  43. Not if you are being paid by the cat. :) And yes, the strlen() response was
  44. damn wrong. It completely ignored the possiblity that fgets() may return a
  45. string that doesn't have a newline at the end. Just the sort of useless answer
  46. that we don't need on comp.lang.c: incorrect, and is directed at the wrong
  47. question anyway.
  48.  
  49. > have yet to use a version of Unix that will
  50. >blow up on forcing a null into a returned NULL pointer.
  51.  
  52. What are you using for a Unix? Are you for real? Boy, you are going to get
  53. flamed for this.
  54.  
  55. >For 18 years, I have coded scary stuff like 
  56. >    *strrchr(buffer, '\n') = '\0'
  57. >and have yet to have a problem.  Try it on your system.
  58.  
  59. I wouldn't write that on a resume.
  60.  
  61. >Any problems?
  62.  
  63. Are you serious? Can you say ``segmentation fault (core dumped)'' if the
  64. newline is not found? Dereferencing a null pointer is illegal in the C
  65. language, and is even caught by many environments that _don't_ have hardware
  66. memory mangement, e.g. the 16-bit compilers under MSDOS!
  67.  
  68. >The mere nature of the author's request would indicate that
  69. >he is looking at text files, (what sense is there doing side-by-
  70. >sides of binaries?)  So, why not a utility that works with, and 
  71. >assumes, text?  Unix text files have \n terminators.  Correct me
  72. >if I'm wrong.
  73. >
  74. >So, why write a bunch of lines of _elegant_ code to simply
  75. >clobber a newline? 
  76.  
  77. Because it's less typing than the inelegant (and incorrect, unrobust)
  78. equivalent?
  79.  
  80. >I also notice that your solution does not take into account any
  81. >output formatting: what happens to the output from f2 when f1 is
  82. >shorter that f2?  From what I see, it starts looking like output from 
  83. >f1. 
  84.  
  85. This was not called for in the informal requirements. In fact, if f1 runs out
  86. of lines, f2 is flushed left. The original posting (which I'm aware you didn't
  87. see) had not specified any sort of separator character, though adding one is
  88. trivial.
  89.  
  90. >Is your version really faster? 
  91.  
  92. Maybe not measurably, but I can't imagine any implementation where avoiding
  93. needless buffering and scanning would not save machine cycles. Not that saving
  94. machine cycles is the primary motivation here.
  95.  
  96. >Does it really matter for the author's
  97. >needs?  Is it easier to follow?  Is it smaller?  Easier to debug when
  98.  
  99. Yes.
  100.  
  101. >buried in a few thousand lines of code?  By the way, isn't the stdio
  102.  
  103. Undoubtedly.
  104.  
  105. >library's intent to create more efficient i/o?  Is getc/putchar really
  106. >more efficient than fgets or fread?
  107.  
  108. In certain contexts, yes. It's not that they are _inherently_ inefficient. It's
  109. improper use that makes approach that makes them inefficient. For instance, it
  110. doesn't always make sense to fgets() something and then scan the results! Why
  111. not just scan the standard IO stream? The macros directly access the buffer
  112. associated with the FILE structure.
  113.  
  114. >I'm new to this group, and your type of response is kind of scary:
  115. >does everyone here have a chip on their shoulder?
  116. >Cut others a little slack!
  117.  
  118. Incorrect answers, or answers to the wrong question are not helpful to anyone.
  119. What is scary is that the proliferation of poor answers continues once the
  120. question has already been beat to death and has been correctly answered by
  121. people who actually _test_ their code, however trivial, before posting it to
  122. the newsgroup.
  123. -- 
  124.  
  125.